A control mechanism for support in a heterogeneously distributed programming environment is disclosed in David D. H. Lin, Behrooz Shirazi & Hassan Peyravi, An Asynchronous Remote Procedure Call System for Heterogeneous Programming, Proceedings of the Annual International Phoenix Conference on Computers and Communications, U.S. Los Alamitos, IEEE Comp. Soc. Press, Vol. Conf. 10, Mar. 27, 1991 (1991-03-27), pp. 153–159, XP000299042 ISBN: 0-8186-2133-8 (hereinafter “Lin et al.”). The Lin et al. mechanism is based on an asynchronous control algorithm for assigning a plurality of responses of a server to queries from a client.
In Lin et al., a method is disclosed in which a time-stamped unique process ID is used to keep track of Remote Procedure Calls (RPCs) and responses thereto. A Remote Procedure Call is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand network details. The RPC protocol uses the “client/server” model. The requesting program is a “client” and the service-providing program is the “server”. Like a regular or local procedure call, a RPC is typically a synchronous operation requiring the requesting program to be suspended until the results of the remote procedure are returned. However, the use of lightweight processes or “threads” that share the same address space allows multiple RPCs to be performed concurrently.
The unique process ID disclosed in Lin et al. is a concatenation of machine-ID, program-ID, dependency-ID and a local time-stamp. The unique process-IDs provide a mechanism to issue certain types of RPCs asynchronously, but process their replies in correct, i.e., synchronous, order.
Additionally, in accordance with the Lin et al. method, three different data structures are used to implement the required control mechanism over the RPCs. The three data structures respectively deal with incoming calls, out-going calls and replies that need to be held for later processing.
A client device, e.g., the device originating an RPC, processes calls and receives messages in an asynchronous fashion. To process RPCs, the client generates a header for each individual call and puts the header on the queue for out-going calls. The header contains the process-ID generated by the client and is used for claiming the reply and for ultimately keeping the desired order of the replies.
When a client processes a received message, it first places the message on a buffer. The client then tries to match the header of the incoming call with the headers in the queue for out-going calls. If there are some headers with the same machine-ID, program-ID and dependency-ID but have a smaller timestamp than the timestamp of the incoming call, the client indicates that there are some RPC replies that have not yet returned and need to be processed before the incoming call can be processed. In this case, the reply is removed from the queue for out-going calls. The desired processing order of the replies is maintained by matching the IDs and comparing the timestamp of each header. The unprocessed replies in the buffer are checked every time a new message is received.
In the server, messages are received, calls are dispatched and results are sent back to the client. The header for an incoming call is put on the queue dedicated for incoming calls. In the meantime, the server resets a timeout condition and prepares for the next incoming message. This monitoring operation continues until the timeout condition is reached. By the time the server stops monitoring the incoming messages on its communication port, control is switched over to the server dispatcher for dispatching the calls on the queue for incoming calls. As soon as the procedure is completed, the result is attached to the corresponding header in the queue for incoming calls and is sent back to the client. After the result is sent, the header of the call in the queue for incoming calls is removed from the queue.
However, the Lin et al. system and method requires much overhead in the processing of RPCs. Thus, a method is desired that would simplify the solicitation and response of RPCs.